## Status: WIP — chip init succeeds, RX data flow still silent

Brings up the RTL8821AU end-to-end except for RX bulk-IN data flow.
Posting so @RomanLut and others can continue the investigation from a
clean checkpoint that builds against current master instead of
resurrecting #22 (which deletes the 8814AU work and has a parallel
dispatch enum that doesn't compose with the `ICType`-based convention
#23-#29 established).

## What works on T2U Plus 2357:0120 (verified on macOS)

- Chip detection: `CHIP_8821_Normal_Chip_TSMC_D_CUT_1T1R`
- 8821 power-on flow (`rtl8821A_card_enable_flow`)
- Firmware download — 8821 blob, signature `0x2101`, FW ready in ~30ms
- MAC/BB/AGC/RadioA register tables via existing `PhyTableLoader` (same
phydm conditional encoding as 8814AU)
- RFE pinmux (`phy_SetRFEReg8821`), band switch 2.4G/5G, channel + TX
power table on ch6/36/100
- USB endpoint discovery: bulk IN 0x84, OUTs 0x05/0x06/0x08/0x09 (vs
8812/8814's 0x81 and 0x02-0x05)
- `libusb_clear_halt` on IN + `REG_USB_HRPWM=0x84` LPS wake

## What's NOT working

- **RX bulk-IN reads succeed at the USB layer but the chip never pushes
data.** 0 RX packets across 15s on ch100 even with the host Mac actively
associated to a busy 5GHz AP. The chip-internal RX-DMA → bulk-IN-EP
binding isn't engaging despite all known init steps.
- TX path is wired (correct OUT EP, no `LIBUSB_ERROR_NOT_FOUND`) but
unvalidated end-to-end on 8821AU — no peer sniffer in this session.

## Regression matrix (Linux trainer-arch, master vs
`feat/rtl8821au-support`)

| Adapter | Test | Result | vs master |
|---|---|---|---|
| 8812AU (`0bda:8812`) | RX | 41 pkts / 15s, 0 errors, `CHIP_8812`
detected | ✓ no regression |
| 8812AU | TX | 15 prints all `rc=1`, 0 failures (2 runs) | ✓ no
regression |
| 8814AU (`0bda:8813`) | RX | 0 pkts | ✓ matches master baseline
(pre-existing) |
| 8814AU | TX | `rc=1`, ~270-320 async failures (timing-variant) | ✓
matches master baseline |

The new `CHIP_8821` dispatch correctly routes 8812 → 8812 path and 8814
→ 8814 path. No misrouting.

## Suggested next steps for whoever picks this up

1. usbmon trace of `aircrack-ng/rtl8812au`'s RX bring-up against an
8821AU on Linux; diff post-fwdl register writes vs ours
(REG_TRXDMA_CTRL, REG_USB_AGG_TH/TO, REG_RXDMA_AGG_PG_TH,
REG_USB_SPECIAL_OPTION).
2. Compare register state post-init (kernel-driver readback vs our
post-init pyusb dump). Same technique that unblocked the 8814AU TX work.
3. Re-read @RomanLut's #22 `HalModule.cpp` for any 8821-specific init
steps I didn't carry over when rewiring through `ICType`.

## What this preserves

- 8812AU support — untouched (default dispatch branch)
- 8814AU support — untouched (#23-#29 work preserved)
- Same `HAL_IC_TYPE_E` / `ICType` dispatch pattern; no parallel enum

## Attribution

8821a HAL data (`Hal8821APwrSeq`, `Hal8821PhyReg`, `hal8821a_fw`) ported
verbatim from @RomanLut's #22 (svpcom/rtl8812au v5.2.20). Wiring re-done
to follow master's existing convention.

Refs #20 (BadPotato1007's underlying request) and #22 (RomanLut's
original port).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: RomanLut <noreply@github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>